Mobile data transmission and data services are constantly making progress. At least in the framework of the currently discussed/developed standard of LTE/LTE-A (Long Term Evolution/LTE-Advanced) in mobile telecommunication, relay systems are studied.
In such relay systems, a relay node RN acts as a transceiver station (like evolved Node_B, eNB) towards a terminal device (such as a user equipment, UE). On the other hand, such relay node relays or propagates signals it receives from a network transceiver device which is referred to as “donor” evolved Node_B, DeNB, and which insofar “donates” resources to the relay node.
It should be noted that in this application, LTE/LTE-A is referred to as a mere example only and that other standards may apply relaying. Hence, insofar as such other standards and/or systems apply relaying in a similar environment as discussed herein below, principles and/or embodiments taught by this invention may likewise be applicable to such other environments under another standard/system. In order to prevent the description from becoming too complex, however, for explanatory purposes, reference is made to LTE/LTE-A, and at least partly also the corresponding terminology is applied.
Relaying is considered for LTE-Advanced as a tool to improve features such as e.g. the coverage of high data rates, group mobility, temporary network deployment, the cell-edge throughput and/or to provide coverage in new areas. Relaying as an important topic for Release 10 has been extensively discussed in 3GPP (3rd Generation Partnership Project). In a relay system, the relay node RN acts as a UE from the DeNB point of view, while it behaves as an eNB for UEs served by the RN. Therefore, the RN supports eNB functionality as well as UE functionality.
FIG. 1 shows an exemplary architecture of a relaying system and elements constituting the relay system and interfaces there between. As shown in FIG. 1, mobility management entities/serving gateways MME/S-GW are connected to an evolved Node_B, eNB, or a Donor evolved Node_B, DeNB. A connection from a MME/S-GW towards an eNB is achieved via an interface S1, whereas a connection from an MME/S-GW towards a Donor eNB, DeNB, is accomplished using an interface S11. Since a Donor eNB may act as a “conventional” eNB as well as a Donor eNB, DeNB, this one is connected via both interfaces S1 and S11 to a respective MME/S-GW. A connection between a conventional eNB and a Donor eNB, DeNB, is accomplished using an interface X2. Likewise, a Un interface interconnects a relay node RN and a Donor eNB, DeNB. The Un interface carries the X2 interface and S1 interface between the RN and the DeNB. The interfaces used for interconnection also represent to a certain extent the layer in the OSI (open system interconnection) signaling model on which these interfaces are applied. The relay node RN, the eNB, and the DeNB at least constitute the evolved UTRAN (E-UTRAN), i.e. the evolved universal terrestrial radio access network. Furthermore, the relay node relays signaling to and from a terminal such as user equipment UE from and to the DeNB. The interface between the user equipment UE and the relay node RN is referred to as Uu interface, which is the same interface as between an eNB and a UE. For the following description, the interface or link between UE and RN is also referred to as access link, whereas the interface between RN and DeNB, in particular the Un interface thereof, is referred to as backhaul link. The interface or link between DeNB and UE is also referred to as direct link.
A relay node thus represents a device comprising a transceiver device, configured to communicate via a first interface (access link) Uu with a terminal and via a second interface (backhaul link) Un with a remote network device DeNB.
One critical issue of a relay system is the capacity of the backhaul link, which may be shared by many relay nodes. For capacity enhancement scenarios, the backhaul link of relay system is a potential bottleneck of relay system. To solve the bottleneck issue, applying multiple component carriers to the relay backhaul link is considered as an appealing approach. Applying principles of carrier aggregation CA to the relay system has not been investigated in Release 10 of LTE. Given that a framework for CA and a basic process of CA operation has meanwhile been determined by 3GPP in Rel10, but not for relay systems, it is useful to investigate the potential issues on applying CA also to relay systems.
However, in connection with carrier aggregation, issues in relation to a dynamic change of aggregated carriers will have to be solved. Dynamic component carrier change may affect the access link as well as backhaul link, i.e. a change on the access link may impact the backhaul link and vice versa. Hence, in regard of applying multiple component carriers to relay system, several different deployment scenarios need to be considered. Among them, multiple component carriers could be applied to backhaul link only, or to relay access link only, or to both relay access link and backhaul link.
When carrier aggregation is configured, the UE only has one RRC (radio resource control) connection with the network. At RRC connection establishment/re-establishment/handover, one serving cell provides the NAS (network access stratum) mobility information (e.g. TAI (timing advance information)), and at RRC connection re-establishment/handover, one serving cell provides the security input. This cell is referred to as the Primary Cell (PCell). In the downlink, the carrier corresponding to the PCell is the Downlink Primary Component Carrier (DL PCC), while in the uplink it is the Uplink Primary Component Carrier (UL PCC). Depending on UE capabilities, Secondary Cells (SCells) can be configured to form together with the PCell a set of serving cells. In the downlink, the carrier corresponding to an SCell is a Downlink Secondary Component Carrier (DL SCC) while in the uplink it is an Uplink Secondary Component Carrier (UL SCC). For the sake of brevity, in the following description PCell and SCell, respectively, are used.
According to the assumption in 3GPP for LTE Release 10 on carrier aggregation, it is possible that a SCell can be activated and deactivated dynamically by the network side (control entities) based on downlink DL and uplink UL traffic requirement of terminals such as UEs. To dynamically change the number of CCs on the radio link between eNB and UE (direct link), the radio resource control, RRC, reconfiguration process has been improved to add/modify/release secondary cells SCells of a UE and specific MAC CE (media access control control elements) have been introduced to activate/deactivate the configured secondary cells.
Since the RN could be considered as an eNB, the carrier aggregation can in principle be applied to the Uu radio link between RN and UE (access link). Likewise, by taking RN as a normal UE the carrier aggregation can in principle also be applied to the Un radio link between DeNB and RN (backhaul link). However, the Rel.10 specifications support CA on the backhaul and access fink but what is done on one link does not have to impact the other link. This makes CA not usable in relay deployment because we need to have disjoint sets of CCs for the backhaul and access links.
However, when taking a closer look at dynamic component carrier change on a relay system's access link, some potential issues have to be considered because of the potential impact to the relay backhaul link, and vice versa, in case of dynamic component carrier change on the backhaul link, some potential issues have to be considered because of the potential impact to the access link.
To explain related issues more clearly, the following FIGS. 2 to 5 are used as possible examples. “Inband” refers to a scenario in which the backhaul link and access link rely on the same component carrier CC, while “outband” refers to a scenario in which the backhaul link and access link rely on a different component carrier CC.
FIG. 2 illustrates a change from inband to outband relay system on CC1. As shown in FIG. 2, during a startup phase, the RN indicates its resource partitioning request on CC1 to DeNB because CC1 is also used as PCell on the access link towards the UE (see FIG. 2(a)). However, during operation phase, the RN may decide to change the PCell of the UE over access link from CC1 to CC3 due to some reasons, such as interference avoidance (see FIG. 2(b)). After the PCell is moved from CC1 to CC3, resource partitioning would not be necessary anymore on CC1. Therefore, the issue is how to inform the DeNB that resource partitioning request on CC1 is not needed anymore during the operation period.
FIG. 3 illustrates a change from outband to inband relay system on CC1. Similar to the previous scenario, in the scenario shown in FIG. 3, after moving PCell of the UE over the access link from CC3 (see FIG. 3(a)) to CC1 (see FIG. 3(b)), the relay system is changed from outband system to inband system on CC1. After the change, the resource partitioning would be necessary on CC1. Similarly, it is an issue how to inform the changed resource partitioning request to DeNB.
According to current specifications in LTE Release 10, a resource partitioning request is only informed to DeNB during RRC connection establishment process, i.e. in the RRC Connection Setup Complete message. After that it is not necessary to change a resource partitioning request because the support of carrier aggregation in relay deployment was not a requirement in Release 10. Therefore, the existing mechanism specified in Rel.10 for a single CC used, both on the access and backhaul link (other CCs can be used on the backhaul and access links but they have to be different), can't be used to solve the issue of a relay system with multiple component carriers on the access link that are also used on the backhaul link.
Similarly, a CC change on a RN's backhaul link is also possible. To illustrate related issues more clearly, the following figures show possible scenarios of a change on a relay node's backhaul link during relay operation mode.
According to the current Re1.10 specifications, a resource partitioning is provided by the DeNB to the RN via RN Reconfiguration message. The message contains the Frequency-Division-Duplex (FDD)/Time-Division-Duplex (TDD) subframe configuration (the resource partitioning, FDD is case of FDD system or TDD in case of TDD system) and the Relay-Physical Downlink Control Channel (R-PDCCH) configuration. The message can also be used to convey the System Information Block Type1 (SIB1) and System Information Block Type2 (SIB2).
FIG. 4 illustrates a change from outband to inband relay system on CC1 due to a component carrier change on the backhaul link. According to the existing specification, with only a single CC used both on the backhaul and access link, during RN startup phase the RN indicates its resource partitioning request to DeNB. However, in the context of multiple CCs, when the additional CC that is also used on the access link (as CC1 in the example shown in FIG. 4(b)) is needed to be activated on the backhaul link due to some reasons, it is not addressed how the DeNB knows about the RN's capability, i.e. whether resource partitioning is needed, on CC1 and how it provides appropriate configuration accordingly. Additionally, if resource partitioning is needed for more than one component carriers, how to provide the configuration is another problem.
FIG. 5 illustrates a change from inband to outband relay system on CC1 due to a component carrier change on the backhaul link.
As shown in FIG. 5, it is possible that a SCell (CC1 as shown in FIG. 5(a)) is removed on the backhaul link. After CC1 is removed, the resource partitioning on the RN's access link is not necessary anymore. It is thus an issue to provide for means to release the configured Un subframe info applied on RN's access link. Again, if resource partitioning is applied for more than one component carriers, how to change the configurations is another problem.
Currently, the configured RN subframe configuration (on the backhaul link) including the FDD/TDD subframe configuration and the R-PDCCH configuration are only released when the RRC connection is released. Definitely, it is not considered a good solution to terminate the entire RRC connection that is shared by all CCs on the backhaul link.
In summary, when carrier aggregation CA is considered in relay systems on the access and backhaul link, it is likely that some SCell is to be added, modified or removed on either backhaul link or access link. Since in current specifications, the negotiation on resource partitioning only takes place in the beginning of a RRC Connection establishment procedure, it needs to be addressed how to configure the subframe partitioning when a new SCell is added or removed or otherwise modified, and how to configure the subframe partitioning for more than one component carriers.
To the inventors' knowledge, during discussion in Release 10 related to the relay system, there are also some proposals on how the RN's capability info is exchanged between the RN and DeNB. According to one proposal (e.g. in R2-104541), several alternative approaches have been proposed to exchange RN's capability info to the DeNB. However, all these proposals are focused on the RN startup phase, which can't be used during the RN's operation phase because the RN's capability info or resource partitioning info would be changed with the CC change on RN's access link and/or backhaul link.
Therefore, there is a need for new approaches to be explored to solve the issues during RN operation phase.
Thus, there is still a need to further improve such relay systems operating on the basis of carrier aggregation on the access as well as on the backhaul link.